---
description: 领域模型是什么？
---

## 领域模型是什么？

<RedSpan>领域模型（domain model）是对领域内的概念类或现实世界中对象的可视化表示。</RedSpan>

领域模型在业务中有一个名字，叫做业务对象模型。从名字可以看出来，业务对象模型是用来描述业务对象之间的引用关系的。


业务对象分为三种：
* <RedSpan>业务角色</RedSpan>：业务角色表示的是一个角色承担的一系列责任。比如收银员，他的责任是计算商品价格，收钱、找零，退换货。
* <RedSpan>业务实体</RedSpan>：业务实体表示的是使用或者可交付的工件，资源、事件。比如电商项目中的商品、发票。
* <RedSpan>业务用例</RedSpan>：实际上业务用例显示的是协作角色与业务实体之间如何执行工作流程，也就是业务链路。 测试用例是业务用例的具象化。

也即是说，业务逻辑流转以及中途所需的角色。



## 模型的分类
### 失血模型
失血模型实际上就是我们的对象模型中只包含我们的get，set方法，像我们的排序，分页等等任何的通用性操作都不会包含在我们的对象中。这种逻辑实际上会让我们的领域模型比较傻瓜式。什么意思呢？我们的失血模型是没有Dao层的，我们所有的业务会全部写在我们的Service当中。所以，一般情况下，不推荐用这种模型的。

优点： 领域对象结构简单

缺点：
* 肿胀的业务代码逻辑，难以维护。
* 无法应对频繁更改的需求。
### 贫血模型
贫血模型实际上就是在失血模型的基础上增加了不依赖于持久化的原子领域逻辑。


不用直接去访问数据库的操作，都可以定义在我们的这个对象当中。比如我们经常会使用到的排序，分页等等操作。这些操作，而任何跟持久化相关的操作，你都需要在业务逻辑层实现。

优点：层次结构清楚，各层级单向依赖。对于少量业务逻辑的应用来说，使用起来非常自然；开发非常迅速，易于理解。

缺点：无法良好的应对非常复杂逻辑和场景。


### 充血模型
更加符号面向对象原则，领域对象不仅仅包含了非持久化的逻辑，甚至包含了持久化逻辑。但是业务逻辑层在充血模型中还是需要的。但是只会做一些整合的操作以及封装事务，其它的操作都会在领域对象中完成。

优点
* 更加符合OO的原则
* Business Logic层很薄，符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重，只充当事务管理以及整合的角色，不和DAO打交道。

缺点

* 职责不好进行划分,我们的业务逻辑到底是划分到我们的哪一个层级呢?是领域对象还是业务属性呢?哪些划分到领域对象呢?而且持久化的内容都放在我们的领域对象里.所以我们在写业务的时候会深入到领域对象去,这对于开发者的水平要求很高,变相的增加了企业的成本.
* 其次,由于充血模型包含了太多的操作,你实例化的时候也会有很大的麻烦,拿到了很多你不需要的关联模型.


### 胀血模型

胀血模型取消了Service层，只剩下domain object和DAO两层

也不用在业务逻辑层面做事务,直接在方法上或者对象上进行事务操作以及授权等等.完全简化代码分层.所有的业务逻辑整合也放在了我们的领域对象里面.简单粗暴.这样其实也算是面向对象,但是代码的维护性太差.

优点：
* 简化了代码分层结构
* 也算符合面向对象设计
缺点：

* 取消了Business Logic层(业务逻辑层)，在Domain Object的Domain Logic上面封装事务，授权等很多本不应该属于领域对象的逻辑，使业务逻辑再次进行到混论的状态，引起了Domain Object模型的不稳定
* 代码理解和维护性差.

失血模型以及胀血模型已经不在被推荐使用。而贫血模型是我们用得最多的,因为充血模型对于程序员要求极高,很多的项目都不会去这样设计,包括如果我去进行这样设计的话,我也不能保证业务人员能够按照标准去进行代码编写.

